Subject: Re: MIB Work Items (abeit old work items)

From: "Shannon Nix" <[email-masked]>
Date: Fri, 03 Feb 95 09:34:12

Peter and David,

This message just bounced... we've had mail trouble

Its not terribly timely since you have distributed the MIB draft already but...

Best regards, Shannon

------- =_aaaaaaaaaa
Content-Type: text/plain; charset="us-ascii"
Content-Description: Session Transcript

While talking to stingray.mcnc.org:
>>> RCPT To:<originator:@stingray.mcnc.org>
<<< 550 <originator:@stingray.mcnc.org>... User unknown
550 originator:@stingray.mcnc.org... User unknown

------- =_aaaaaaaaaa
Content-Type: text/plain; charset="us-ascii"
Content-Description: Recipients of this Delivery

Bounced, cannot deliver:
   originator:@stingray.mcnc.org
Sent successfully:
   <[email-masked]>

------- =_aaaaaaaaaa
Content-Type: message/rfc822
Content-Description: Returned Content

Date: Fri, 27 Jan 95 11:53:12 
From: "Shannon Nix" <[email-masked]>
Encoding: 4683 Text
To: [email-masked]
Originator: [email-masked]
Subject: Re: MIB work items

          Hi,
          
          One couple small comment re: flow control objects.
          
          1.  I would prefer not seeing non-standard flow-control mechanisms 
              instrumented in the MIB, namely ENTER/EXIT BUSY.
          
               The implementation agreement reached was: "A DLSw node shall 
               support no-less than "fixed rx, adaptive tx".
          
               However, recognizing that ...
               
               a. there are XBusy boxes in the field 
               b. Instrumenting an SNMP agent might be less 
                  effort (certainly independent effort) than bringing the    
                  whole install base to standards level
          
                ... I could be placated by adding some words characterizing  
                the non-standard enumerated values as non-standard.
          
                Also I think the order mentioned (pacing vs XBusy) has some
                implied message as well.
           
          2.   As agree with your suggestion on removing AdminFlowControl 
               from the transport connection.  I certainly am opposed 
               to coercing a receiver to support fixed pacing.  The decision 
               to vary the window size should be left up to the receiver.
          
          Best regards, Shannon

______________________________ Reply Separator _________________________________
Subject: MIB work items
Author:  [email-masked]
Originator: 
[email-masked] at Internet-Gateway
Date:    1/20/95 9:05 PM

David needed some input on a few of the work items from San Francisco
in order to put out the new draft MIB to be reviewed at the end of the
month.  To keep things moving, I gave him the following input.  You can
comment online here or wait for the conference call.

(1) Flow control objects
      These objects were all messed up (did not distinguish xmit and
      rcv roles or allow to express both xBUSY and pacing support).
      I recommend the following, after some thought:

      dlswFlowCntlSupport (the product's code capability) should be
          split into two objects:
        dlswXBusySupport
          1 - none
          2 - receive only
          3 - send and receive
        dlswPacingSupport
          1 - none
          2 - fixed receiver and adaptive sender
          3 - adaptive receiver and adaptive sender

      dlswAdminFlowCntlMode should be deleted.  The RIG did not define
          a way to signal/negotiate a "preferred" flow control mode
          with a partner DLSw.  So the only value left is to be able
          to force an adaptive receiver box into fixed receiver mode.
          I don't see very much value in being able to do this.

      dlswOperFlowCntlMode should be renamed and moved to be on a
          transport connection basis.  It is possible to be doing
          pacing and enter/exitbusy independently on different TCs.
          Suggested allowable values:
          1 - undefined  (before capex is complete)
          2 - ENTERBUSY / EXITBUSY
          3 - Pacing
          4 - Other  (accomodates vendor-specific mechanisms)

      dlswInitRecvWndwSize is fine as is (with the edits from SF)

(2) Description of dlswStatus
      The status of the DLSw part of the system.  Changing the value fro
      "active" to "inactive" causes DLSw to take the following actions:
         - disconnect all circuits through all DLSw partners
         - disconnect all transport connections to all DLSw partners
         - disconnect all local DLC connections
         - stop processing all DLC connection set-up traffic
      Since these are destructive actions, the user should query the
      circuit and transport connection tables in advance, to understand
      the effect this action will have.

      Changing the value from "inactive" to "active" causes DLSw to
      come up in its initial state (transport connections established,
      ready to bring up circuits).

(3) Enumerated reason code for circuit disconnect

      1 - Received HALT_DL from partner
      2 - Received HALT_DL_NOACK from partner
      3 - Received DISC from end-station
      4 - Detected DLC error with end-station
      5 - Circuit-level protocol error (e.g., pacing)
      6 - Transport connection closed normally
      7 - Transport connection closed due to error
      8 - Operator-initiated (mgt station or local console)

    (discussion question:  should we distinguish for 6-7 why the
     TC was closed and what the errors may have been?)

Peter

------- =_aaaaaaaaaa--